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« 

METHODS AND APFARAXUS FOR CQNTRQLUNQ SIGNALLING GATEWAYS 
BACKGROUND OF THE INVENTION 
5 Field of the Invention 

* 

The inveniion relates to methods, and related apparatus, ifor controlling processing entities used, 
for instance^ in communication systems such as for the control of signalling trafJEic between a 
signalling gateway and a. plurality of application server processes. 

10 

Backgroimd Art 

Establishing connections between two telephones involves a complex interaction of digital 
messages, hereinafter referred to generally as signalling. Nowadays telephone systems pertbim 

15 what is known as "out-of-band" signalling. Out-of~band signalling means that the 
communications required between the switches and other equipment in the network take place 
on communication channels other than the channel by which the voice or data flows. Typically, 
the out-of-band signalling takes place by means of digital commumcation channels. Thus, the 
pubhc switch telephone network (PSTN) generally uses tw-o types of channels, media and 

20 signalling. 

Several protocols have been defined for oat-of-band signalhng. The most commonly used 
protocol; in North* America, Asia and Europe, is known as Signalling System No. 7 (SS7). 
However, the SS7 protocol defines more than just a protocol for communication between 
25 switches. It also defines an entire switching network for &cilitating signalling for call 
establishment, routing, and information exchange functions of switched circuit networks. 

Since thfe amount of data transfeired over data networks is now much larger than the voice 
traffic that is carried over the PSTN» cairters are in die process of consolidating both types of 
30 networks. Tn addition, telecommmueation networks arc increasingly making use of standard 
computing hardware in order to reduce IT costs. 

Therefore, there is a trend in die telephone industry to migrute telephone sys^ms using SS7- 
based networks for signaUing to Internet Protocol (IP) networks. The' Internet protocols are 
35 standardised by the Internet Engineering Task Force (IETF). Moving either or both of the media 
and signalling channels to an IP infrastructure involves the use of very dif^rent technologies 
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and can b© done indepCTdently. The SlGTRAN IETF working group is currently in the process 
of defining the protocols for back-hauling SS7 signalling messages across IP networks. 
Generally spealdng, signalling across an IP network involves replacing the lower levels of the 
SS7 layered protocol communications and transport layers with IP. network protocol 
5 communications and transport layers. 

The SIGTRAN group have taken the initiative to define open standards for tianspomng SS7 
over IP networks. With SIGTRAN technology, telephone ser\aces which today lie on top of 
SS7 networks, can run Application Servers (ASs) lying on top of IP networks. The 
10 interworking with SS7 networks is performed by SIGTRA2>I signalling gateways (SGs). 

For additional information regarding SS7 network switching over IP networks, reference may 
be made to the (IETF) working drafts "Signalling Connecting Control Part User Adaptation 
Layer (SUA)" available from the tETF website at wvvw.ietf.org, and IETF RFC 3332 "SS7 

15 MTP3 - User Adaptation Layer (M3UA)", available from the DETF website, and which are both 
incorporated herein by reference as if reproduced in ftill. It is noted that the SUA document is a 
work in progress and is diereforc subject to change. However, th<^e documents, which will be 
referred to herein as the SIGRAN documents, exemplify the changes necessary to a standard 
SS7 signalling system for its implementation in an IP network conte?tt. As well as defining the 

20 functions of signalling gateways and signalling gateway processes, the SIGTRAN documents 
referred to above specify in detail the protocols to be implemented between a signalling gateway 
and a application server. 



For more general background information regarding SIGTRAN protocols, reference may be 
25 made to the International Engineering Consortium, in document "SS7 Over IP Signalling 
Transport and SCTP,** which is available from the DSC website www.iec.org. and which is 
incorporated herein' by referrace as if reproduced in JEull. 



30 



To enhance the availability of the signalling gateway, it can be distributed over several 
processes running in one or several computers, each of them being a Signalling Gateway 
Process (SGP). Evciy SGP belonging to a particular SG has the same SS7 point code (or the 
same list of PCs), with each SGP generally being connected to the SS7 network through, 
redundant links that are selected in conventional manner via Signalling Link Selector (SLS) 

• • • 

values present in the SS7 messages. 



35 
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On the IP network side, each SGP is connected to the ASPs running the services. Each AS, 
which can typically be identified with a single logical sendee, such as a Short Message Service 
Centre (SMSC), can also be implemented in a distributed manner by one or more processes or 
computers - referred to as the ASPs. To provide improved reliability, each SGP is typically 
directly connected to each ASP through an Stream Control Transfer Protocol (SCTP) 
association such that there is one association between each SGP and each ASP, 



However, ttie use of redundant links to the SS7 network, which is highly deshrable to ensure 
fault tolerance of the gateway, can result in latency and performance Inefficiencies within the 
10 gateway since signalling messages may need to be transmitted between elements of the gateway 
itself in order to reach signalling unit hardware which carries an outboxmd SS7 link selected in 

■ 

accordance with an SLS value of a message. 



It is an object of the present invention to overcome this and/or other drawbacks with the prior 
15 art. 

mm ^ 

SIJMMARY OF THE INVE]NTIQN 



I 

} 

« 
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In brief, the present invention provides a method for operating a signalling gateway comprising 
determining information enabling an application server to identify a signalling gateway process 
to which to direct a message destined for a particular point code and maldng said information 
available to the application server. 

In preferred embodiments, the information takes the fonn of a routing table that ser\'es to 
distribute signalling gateway process identifiers over possible SLS values by, for instance, 
niapping process instance identifiers to possible signal link selector values for messages sent by 
the application server. ' 

Thus, an application server can obtain more specific information enabling it to detenirine 
directly a signalling gateway process to which to iransmit messages destined for a particular 
point code. With use of a distributed gateway architecture where signalling links are distributed 
over redundant hardware, the SGPs can be hosted so as to each have direct access to signalling 
unit hardware for a subset of the signalling links. By allowing the application server processes 
the possibility to determine to which SGP each message diould be directed, retraiismission of 
messages wi&in the signalling gateway can be avoided. 



I 
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In preferred embodiments, the signalling gateway can be responsive to a change in the status of 
links upon a route to a particular point code to recalculate the routing table for that point code 
and transmit the recalculated routing table to an application server in a fiirtlier message. In this 
way, it can be provided that the ASPs select SGPs on the basis of the SLS values taking into 
5 account the availability or not of the signalling links to which each SGP has direct access. 

In an SS7 network, the routing decisions arc taken by the sigtiailing network management 
flinctions of the MTP3 layer. Wlienever a change in the status of a signalling Jink, route or 
point code occurs, 3 different signalling network management functions (ie signalling traffic 

10 management, link management and route management) are activated. However, only a subset 
of the routing information gathered by the MTP3 layer is transmitted to the remote AS 
SIGTRAN layer (M3LIA or SUA as the case may be). In the systems envisaged by the 
SIGTRAN documents, only the status of the remote Point Code ("available", ''restricted" from 
SO point of view, or "not available") is reported to the remote AS. The Signalling Gateway 

15 maintains the status (a^'ailability, restriction, and/or congestion of route to destination) of tfce 
individual routes^ derives the overall availability or congestion status of the destination firom the 
status of the individual routes, and informs the ASF of this derived status whenever it changes. 
In at least preferred embodiments, the routing table is included in this message transmitted &om 
an SGP to an ASP that serves to indicate the accessibility of the point code concerned, in 

20 accord^ce with the SIGTRAN documents, a separate routing table being established for each 
destination poiut code. 

Other aspects of the invention provide methods for operating a corresponding application server 
process, signalling gateway'eiements and application server elements arranged to carry out the 
25 above described methods and a signalling gateway having a redundant set of signalling links to 
a signalling network and having a single point code, or set of point codes* therein, and 
comprising a plurality of such signalling elements, ^^-ith each signalling element comprising a 
signalling unit to which a subset ofthe signalling links arc connected. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

An embodiment of the invention will now be described, by way of example only, with reference 

« 

to the accon^anying' drawings in which: 



. 4 



35 Figure 1 showis the. general configuration of a signalling gateway; 
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Figures 2a and 2b illustrate the layered protocol communications schemes of a Signalling End 
Point a Signalling Gateway Process and an Application Sender Process; 

Figure 3 illustrates associations between Signalling Gateway processes and Application Server 
processes and signalling connections to point codes; 

Figure 4 shows an exemplary sequence of events and signalling network management message 
exchanges; 

Figure 5 illustrates the main processes that carried out by signalling gateway processes in order 
to implement this invenlioi^ 

Figure 6 illustrates steps of a process carried out by an application server process in order to 
send a message. 



DETAH^D DESCRIPTTQN OF THE PRJEFEKRED EMBODIMENTS 

_ • • 

Figure 1 shows the general configuration of a signalliug gateway 100 intercoimccting an SS7 
15 network 110 and a series of Application Servers (ASs) 130 via an IP Network 120. Figure 2a 
and 2b illustrate the layered protocol communications architecture of the various components. 



SS7 Signal ttansfer Point (STP) or Signal End Point (SEP) 200 includes the MTPl. MTP2, 
MTP3;, SCCP and SCCP user part layers. As is known in tlie prior art, a Signal Transfer Point 

20 (STP) or Signal End Point (SEP) 200 routes SS7 signalling within the SS7 network and 
manages varions signalling links which comprise the SS7 network. Routing is accomplished by 
processing of the routing label of an SS7 message by the Message Transfer Part (MTP) 
functionality. The MTP layers comprise three levels. Levels 1 and 2 are used for the transfer of 
$S7 messages from one point to another over an individual signalling link. Level 3 is used for 

25 the transfer of SS7 messages over the SS7 network beyond the requirements of individual link 
transmission. The MTP3 layer is mainly dedicated to ensuring the delivery of incoming and 
outgoing messages (such as discrimination, distribution and routing), and the nciwork 
reconfi^oratiob (such as traffic management, route management and link management). 

* * 

30 Conmiunication between Signalling Gateway Processes (SGPs) of the SG 100 and Application 
Server Processes (ASPs) within the ASs 130 is carried out using a transport layer defined by the 
SIGTRAN workine group and referred to as SCTP (Stream Control Transfer Protocol) which is 
defined in RFC 3309. Signalling Gateway 100 terminates the MTPl, MrrP2, MTP3 and SCCP 
layers ^d includes a Nodal Jnterworking function (NIF) as well as SUA, SCTP and IP layers. 

35 Each AS 130 inchides IP, SCTP, SUA and SCCP user layers. Signalling Gateway 100 thus 
terminates the SS7 lowdr layers and encapsulaftes their payload data into SCTP messages to 
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send them to an Application Server 130, The AS terminates the SCTP layers, processes the 
signalling messages and replies to the SG 100 in the same way. In the case of SS7 and M3UA 
interworking, the M3UA adaptation layer is designed to pro\'ide an extension of the MTP3 layer 
as shown in Fig 2b. 

■; 5 

These architectures are well known to those skilled in the relevant art and are described in the 
SIGTRAN documents, referred to above. 

Figure 3 illustrates the interconnection of a plurality of SGPs, such as SGFl and SGP2 to a 
10 plurality of ASPs, such as ASPl, ASP2 and ASPS via a plurality of SCTP associations 300. 
The architecture is such titxat each SGP is hosted in a machine that contains the signalling units 
that provide only a subset of the MTP2 signalling links to SS7 network 110 available on the 
.1 SG. 

15 On the SS7 network, the routing decisions are taken by the signalling network management 
functions of the MTP3 layer. Whenever a change in the status of a signalling link, route or 
, points occurs, 3 different signalling network management functions (ie signalling traffic 

management, link management and route management) are activated. The protocols defined in 
•! the SIOTRAN documents provide for a subset of the routing information gathered by the MTTS 

! 20 layer to be transmitted to the remote AS SIGTRAN layer (M3UA or SUA as the case may be). 

■ 

i Basically, only the status of the remote Point Code ("available'*, "restricted" from SG point of 

view, or 'Viot available'^ is reported to the remote AS by means of DUNA (destination 
unavailable), DRST (destination restricted), DAVA (destmatton available) SIGTRAN messages 
respectively. 

I 25 

The DUNA message is sent from an SGP in an SG to all concerned ASPs to indicate that die SG 

« 

has determined that one or more SS7 destinations are unreachable* It is also sent by an SGP in 

response to a message from the ASP to an unreachable SS7 destination. As an iniplcmentatiozi 

option the SG may siippre.ss the sending of subsequent "response" DUNA messages regarding a 

30 certain unrcacliable SS7 destination for a certain period to give the remote side time to react. If 
■ • 

\ there is no alternate route via another SG, the MTP3-User at the ASP is expected to stop traffic 

to die affected destmation via the SG as per the defined MTP3-User procedures. 

I 
I 

* 

The DUNA message contains the following parameters: 

35 

i • * * * 

' Network Appearance Optional ' ' 

200314333-l.EP ' ' . 
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Routing Context Optional 
Affected Boint Code Mandatory 
INFO String Optional 



4 

I 



10 



15 



20 



25 



30 



35 



The optional INFO String parameter is defined 50 as to be able to cany any meaningful XJTF-S 
character string along with the message. Hie length of the INFO String parameter is from 0 to 
255 octets. No procedures arc specifically identified in the SIGTRAN documents for its use but 
it is suggested that the INFO String may be used for debugging pinposes. The DRST, DAVA 
and DAUD messages have similar formats. 

In the case of a distributed Signalling Gate^K^ay in which each SGF is hosted in a machine that 
contains the signalling units that provide only a subset of the MTP2 signalling links to SS7 
network 110 available on the SG, the information available on the AS side, and provided by the 
SIGTRAN (M3UA or SUA) layer in accordance wth the protocols described in the SIGTHAN 
documents is therefore not sufficient to allow an ASP to identUy the SGF that contains the SS7 
signalling link that corresponds to a particular SLS value for a given destination point code. 
Thus if the ASP sends a message to an SOP that does not contain the right signalling ltnk» the 
selected SGF must tn a separate step forward the message within die SO to the SGP thai does 
contain the signalling link. 

A protocol will be described below which is based on messages embedded in the SIGTRAN 

. -J 

messages by means of the usage of "info string" field- By taking advantage of this extra 
information, the ASFs are able to determine the SGP tliat contains die signalling link, on which 
the message mvst be forwarded, directly. 

The protocol, which will be referred to as RSIG in this document^ is implemented by 4 
messages: 

• ^ m 

ROUTING^INFO^CAPABnUTYJREQ 

■ • 

This message is sent from the ASP to the SGP embedded in an ASP-ACTTVE SIGTRAN 
message to determine whether the remote SGF supports the RSIG protocol, to gather the RSIG 
identifier of the remote SGP and to indicate that this ASP may request RSIG information from 
die SGP. Tie" ASP sends this message to each SGP in the SG in order to collect all the RSIG 
IDs. 
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ROUTING^INf 0„CAPABILITY_ACK 

This message is sent from the SGP to the ASP, in an ASP-ACTIVE-ACK SIGTRAN message 
in response to a received ROUTING_TNFO_REQ message, to indicate fliat the SGP supports 
5 the RSIG protocol and that the SGP autliorizes ihe ASP to gather RSIG information and to 
report the SGP's RSIG identifier. 

ROUTESIG^TABLE 

10 Tliis message is sent by an SGP to the ASP, in a DAVA SIGTRAN message to indicate the 
routing (for each SLS) for a particular destination. 

ROUTING_n^O_REQ 

15 This message is sent by an ASP to tlie SGP, in a DAUD SIGTRAN message to indicate that as 
part of the audit of the specified destination, the routing table is requested. The DAUD message 
is defined in the SIGTRAN protocols to be sent from the ASP to the SGP to audit the 
availability or congestion state of SS7 routes from the SG to one or more affected destinations. 
The format and description of DAUD Message parameters is the same as for the DUNA 

20 message described above. This message has an immediate effect in the sense Hhat the routing 
table corresponding to the audited PC is made immediately available by the SGP (by means of a 
DAVA containing a RSIG ROUnNGjTABLE message) bat it also indicates, in the SGP,, that 
each time an event occurs that affects the routing of the PC concerned, the SO must inform the 
ASF. By this means^ the information sent by the SGP$ to the ASPs is limited to the set of 

25 remote PC's that each ASP needs to handle. 



As "info string" field must be contain only ASCII characters, the messages of the RSIG 
^ • • . . 

protocol are based on ASCII only and are described by die following ABNP grammar (see 

■ 

• • • 

1 RFC2234) description:' 

j 30 • • - • 

* • • • 

RSIGMessage = RSIGToken SXJVSH Version SBP cnessageBody 

messageBody « X*l( Routinginf oCapabilityReq / 
j RoutsingXnfoCapabilltyAcUc / 

j RoutingTable / 

i 35 ■ Rout:ingln£okeq ) 



I 

■ 

i 200SI4333-1 EP 
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Rou t iuglnf oCapabi 1 i tyReg 
RBKKT 



Routinglnf oCapabilityReqToken EQXJAL LBRKT 



RoutinglnfoCapabilityAckToken EQUAL LBRKT 



RoutinglufoCapabilityAck = 
RICAParamet exrs R5RKT 

RoutingTable = Rout ingTable Token EQUAL LBRKT SLSTable RBRKT 
Routin^XxifoReg = RoutinglnfOR^qToken EQUAL LBRKTX RIRParameters 



RBRKT 



•i 



RICAParameters = RICASGPId COMMA RICAResult 
10 RICASGPId = RICASGPXdTOken EQUAL 1*3 <DIQIT) 

RICAResult » ResultTcrken EQUAL RtCAResultValue 

RIRParameters = RIRInfo 

« 

RIRInfo 5- l^IRinf oToken EQUAL RIRInf oEnableToken 

* 

SLSTable = (SLSXTUTable / SLSANSXTable) 
15 SLSITUTable SLSXTUTableToken EQXJAL LBRKT 5I*SITUTableResult RBRKT 

SLSAKSITable = SLSANSITableToken EQUAL LBRKT SLSANSITableResult RBRKT, 



20 



RICAResultValue a 1*2 (DIGIT) ; today 2 values are detinedx 

; => 1 : OK, tb.e capability is supported 

/ => 2 t KO^ tbe capability is not supported 



25 



SLSITUTableResult =^ 16*16 (1*3 (DIGIT) COMMA) 1*3 (DIGIT) 
SLSAUSITableResulC = 32*32 (1*3 (DIGIT) COMMA) 1*3 (DIGIT) 

Version = 1*2 (DIGIT) ; today, only version 1 is defined 



■ 



30 



35 



DIGIT 
SLASH 
SP 

HTAB 

CR 

LP. 

• 

BOX. 

WSP 

S2P 

LWSP 

LBRKT 



a %x30-39 
=f %X2F 
= %x20 
= %x09 
8 %3cOD 
« %XOA 



; space 

; horizontal tab 
; Carriage return 
; linefeed 



« (CR CLPJ / ) 

= SP / HTAB ; wiiite space 

= ( WSP / EOL) 

= *( WSP / EOL ) 

» LWSP %X7B LWSP ; " { 
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RBRKT 
COMMA 
£QUAL 



LWSP %X7D IiWSP ; 
IiWSP %x2C LiWSP ; 



11 II 



= I,W$P %x3D IiWSP ; 



•I _ II 



5 RSIGToken 

RlCA^GPidToken 
RXRZnfoTokezi 
RIIlXnfcEziableToKe33- 
RoutinglnfoCapabilityReqToken 
10 RoutijxglnfoCapabilityAckToken 
Rout ingTabl eToken 
Routing InfoReqToken 

Result Token 
SLiSlTUTableXoken 
1 5 SLSANS ITabl eToken 



"RSIG") 

'»RICASGPID" / '*RICASI") 
**RIRI" ) 

'*RICR"} 
''RXCA" ) 

^^RIR" ) 

*'RES" / *'R") 
'•St.SANSITA3" / "'SAT") 



20 
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It will be appreciated that a decoder of such a grammar can be readUy implemented with 
commonly available tools. 

In the following, an exantple will be given of behaviour for the system illustrated in Fig 3 with 
an ASP and a SQ 100 composed of 2 SGPs, SGPl and SGP2. SGPl and SGF2 arc shown as 
being hosted on physically separate hardware platforms interconnected by an internal local area 
network. Each component is assumed to be configured to make use of the RSIG protocol. 



The exemplary SS7 topology shown in Fig 3 is as follows: SGPl contains 2 signaUing links: 
link 1 1 and Link 21; SGP2 contains 2 signalling links: link 12 and link 22. SG 100 is connected 
to PC 10 by linkset 1 and to PC 1 1 by linksct 2. A linkset is a number of signalling links that 
directly interconnect two signalling points and which are used as a module- links within the 
30 linkset being selected by means of a the SLS values in each message. Tt will be understood that 
the separate signalling links within the linksets arc generally always distributed over different 
SGPs for redundancy reasons. 

The SG 100 is connected in associated mode to 2 adjacent nodes: PC 10 and PC 11. In this 
35 example, two other remote point codes, are also available on the netr^'ork: PC 20 and PC 21. 
Each of them is reachable via 2 routes. The network is assumed for the purposes of example to 
be an ITU network. 
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An exemplary sequence of events and signalling network management message exchanges is 
shown in Fig 4 and the main processes used in signalling gateway 100 are illustrated in Fig 5. 

Initially the ASP signals in conventional manner to the SGPl and SGP2 that it is up using 
respective ASP_IJP messages which are acknowledged by ASP_UP_ACK messages as shown 
in Fig 4, 

The use of tht; RSTG protocol to pass routing infomiation between ASP 130 and SGPl and 
SGP2 will now be described in relation ta steps 50O to 590 as follows. 

Step 500: When the ASP is able to handle traffic it informs SGP J by sending an ASP_ACTTVE 
message in which a ROUTlNGJNFO_CAPABILITYJ^Q tnessage is embedded. The 
ROUTINGjNFOjCAPABELITYJtEQ message is fonnatled as follows: 

RSIG/l 

Where RSIG is the ABNF string used to identify the RSIG protocol, 1 is the version of RSIG, 
RICR is the ABNF string used to identity a ROUTlNG_INFO_CAPABTLITY_REQ RSIG 
message. 

Step 510: SGPl replies to ASP 100 using an ASP_ACTiVE_ACK message in which is 
embedded an ROUTING_mFO_CAP ABI1.ITV_ACK message. SGPl has the RSIG capability, 
and flius it authonsses the ASP to take advantage of ttiis capability and it informs the ASP that 
its RSIG identifier is 1 1 1 . The ROUTING JNFO_CAPABILIlY_ACK message is formatted as 
follow: 

RSIG/l 

RICA = { • ' 

RXCASI =» XXX, 
R = 1 

} 

Where RSIG is the ABNF string used to identify the RSIG protocol, 1 is the version of RSIG, 
RICA is the ABNF string used to identify a- ROUTING_B^O_CAPABILrl'Y_ACK RSIG 
message, RICASI indicates an SGP Identifier (value: 111), R indicates the result (value: I. 
meaning that it is OK). 

200314333-1 EP 
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The SGP identifiers are allocated and managed by one of the SGPs which is designated a 
"master" SGP in any suitable way. 

5 This registration process is illustrated by funcriorkalit>' 600 in Fig 5 which is present in each 
SGP. In the example of Fig 4, the registration process is then repeated for SGP2, as follows. 

Step 520: ASP 100 informs SGP2 of its ability to handle traffic using a ASP^ACTIVE message 
in wliich is embedded an ROUTING_INFO_CAPABILTTY_R£Q message to check that SGP2 
10 has the RSIG capability. 

This second ROXJT1NGJNFO_CAPABILITYJIEQ message is fonnatted as follow: 

RSIG/l 
RICR «a {} 

15 Step 530: SGP2 replies to ASP 100 using a ASP_ACTIVE_ACK message in which is 
embedded an RGUTING^INFO^CAPABILTTY^ACK message. It has the RSIG capability;, it 
authorizes the ASP to take advantage of this capability and it informs the ASP tiiat its RSIG 
identi fler is 222. 

The ROUTING INfO;j:APABILmi'_ACK message from SGP2 is formatted as follow; 
20 RSIG/1 
RICA = { 

ftZCASI = 222, 
R = 1 

} 

25 

Next a destination query process, illustrated by functionality 620 in Fig 5 is carried out in 
relation to a particular destination point code selected by ASP 130. Within SG 100 each SGP 
maintains a routing table for each SS7 destination linking SLS values, SGP IDs and signalling 
link identifiers. These routing tables are updated intertially to SG 100 based on infomxatioD 
30 received from the SS7 network. In one embodiment for instance, whenever a TFP/TFA or TFR 
message is received from the SS7 network or a local signalling link changes status* each SGP 
forwards this information to the designated "master' ' SGP which can serialise the recalculation 
of the routing tables and their broadcast to each SGP. 

35 Step 540: ASP 130 wants to AUDIT the SS7 remote destination 20. It sends an SIGTRAN 
DAUD message for this Point Code and informs SGPl that it wants to be notified of routing 
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changes by including a ROUTDSfG^INFO^RJEQ message in the DAUD message. This 
infonnation is distributed internally by the SG to all SGPs. 
The ROUTlNG_INFO_REQ message is formatted as follow: 

RSIG/l 

RiR « { 

RIRI (f)N 

1 



10 



where RSIG is the ABNF string used to identify the RSIG protocol, 1 is tiie version of RSIG, 
RJR is tlic ABMP siring used to identify a ROUTlKG_INFO_REQ RSIG message, BHa 
indicates if the ASP wants to enable or disable the RSIG feature for this destination (value ON: 
feanu*e is enabled). 



15 



Step 550: immediately, SGPl retrieves the routing table for the destination and reports the 
status of the SS7 remote destination 20 (as specified in the SIGTRAN procedure) and includes 
the routing information in the DAVA message using a first embedded ROTJnNGJTABIJE 
RSIG message. 



20 



25 



30 



35 



The first ROUTING JTABLE message in this example is formatted as follows (for the iTU case 
where the SLS has 4 bits): 

RSIG/l 
RT = { 
SIT = { 

111, 
222, 
111, 
222, 
XXI, 

iix, 

222, 

iix* 

222, 
Xll, 
222, • • 
Xll, 
222, 
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222 

} 

} 

5 

where RSIG is vhe ABNF string used to identify iJie RSIG protocol, 1 is the version of RSTG, 
RT is the ABNF string used to identify a ROUTINGjrABLE RSIG message, SIT indicates an 
ITU Routing Table. 

10 This first ROUTINGJTABLE message indicates to ASP 130 that, to reach the remote 
destmation 20, it is optimal for the ASP to take the decisions sho\m in Table 1 according to Ae 
SLS value of the MSU, 



SLS value 


SGP 


0 


SGPl tKSJGId; 111) 


1 


SGP2 (RSIG Id: 222) 


2 


SGPl (RSIG Id: 111) 


3 


SGP2 (RSIG Id: 222) 


4 


SGPl ORSIGId: 111) 


5 


SGP2 (RSIG Id: 222) 


6 


SGPl (RSIGTd: 111) 


7 


SGP2 (RSIG Id: 222) 


8 

* 


SGPl (RSIG Id: 111) 


9 


SGP2 (RSTG Id: 222) 


10 . 


SGPKRSIGM: 111) 


11 


SGP2 (RSIG Id: 222) 


12 


SGPl (RSIG Id; 1 1 1) 


13 


SGP2 (RSIG Id: 222) 


14 


SGPl (RSIG Id: 111) 


15 


SGP2 (RSIG Id: 222) 

* 



.: 15 Tabic I 

* 

. * 

Jn the following steps, various routing change scenarios %vill be described and» in each case, a 

:* routing change process 620 is carried out. Process 620 basically comprises 3 steps — detection 

of the routing change, recalculation of the routing tables and communication of the i^dated 

* 
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routing tables to ASP 130 embedded in DAVA niessagc$. As before in some embodiments 
each SGP may forward routing change intbrmatiou to the designated '^master'* SGP whicb 
recalculates the routing tables and broadcasts Ibem to each SGP. Alternatively, the routing 
tables could be recalculated within the SGP that first detects the routing change event and 
broadcasted by that SGP to all the other SGPs. The DAVA niessages including the updated 
Toutuig cables inay be sent out to ASP 130 by any of the SGPs and so any suitable and/or 
convenient mechanistn for selecting an SGP to respond may be used, such as having tlie master 
SGP respond (if there is one), having the SGP that delects the routing change respond. Or having 
the SGP that originally received the ROUTING_INFO_RjEQ message Ixom the SGP. Of 
course, ill some embodiments all necessary routing tables may be calculated, configured or 
otherwise determined in advance and stored for a set of potential routing changes. 



m 



15 



20 



25 



30 



35 



Step 560; Tn this example, it is imagined that SGPl detects for instance that signalling link 1 1 is 
no longer operational for whatever reasoni and implements a routing change. ASP 130 has 
requested to be notified for routing changes to destination 20 only* so SGPl intbrms ASP with 
a DAVA message containing a recalculated second ROUTTNGJIABLE RSIG message, 
formatted as follows: 

SXG/X 
= { 

SIX =: { 

222, 
222, 

« 

222, 
222, 
222, 
222, 
222, 
222, 
222, 
222, 
222, 
222, 
222 « 
222. 
222, 
222 

> 
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) 

This second routiug table indicates to ASP 130 that for all values of the SLS field in tlie MSU it 
is optimal for the ASP to send the MSU to SGP2 (RSIG ID 222). 

Step 570: Now for the purposes of example, imagine that SGP2 receives, on the SS7 network 
side, a transfer prohibited (TFP) signal indicating that the ftrst route (linkset 1) is unavailable 
for destination 20. The receipt of this message results in recalculated routing tables being 
broadcast to all SGPs and SGPl informs ASP 130 with a DAVA message containing a third 
ROUTING JTABLE RSIG message, formaUed as follows: 

RSIG/l 
RT » { 
SIT « { 

111, 
222, 

111/ 
222, 

111, 

222, ' 

111, 

222, 

111, 

222, 

111, 

222, 

222, 
111, 
222 • 

• 

} 

This third ROUTTNGJTABLE message indicates to ASP 130 that, to reach the remote 
destination 20, it is once again optimal for the ASP to take the decisions 5ho\^'n in Table 1 
according to tiiie SLS value of the MSU. 
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Step 580: Now for the purposes of example, imagine that SGPl receives, on the SS7 network 
side, H transfer prohibited (TFP) signal indicating that the second route (linkset 2) is unavailable 
for destination 20. Consequently, destination 20 is now not accessible. So SQFI informs ASP 
with a DUNA message which does not contain any RSIG information since no routmg table is 
5 necessary - die destination being not accessible. 



Step 590: SGPl receives, on the SS7 network side, a transfer allowed (TFA) signal indicating 
that the second route (linkset 2) is now available tor destination 20- So SGPl informs ASP with 
a DAVA message containing a fourth ROUTING_TABLE RSIG message, formatted as 
follows: 

RSIG/l 

« { . 

SIT = { 

222. 



10 



15 



20 



25 



30 



111, 

222, 
111, 
222, 

111, 
222, 
111. 
222, 
111, 
222, 
111, 
22a, 
111, 
222 



1 



) 



This fourth ROlJnNG_TABLE message indicates to ASP 130 that, to reach the remote 
destination 20. it is once again optimal tor the ASP to take the decisions shown in Table I 
35 according to the SLS value of the MSU . 
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Figure 6 illustrates the process carried out by application server process 130 in order to send a 
signalling message. First the SLS value is extracted firom Ibe message in step 630, Chen the 
routing table is accessed iii step 640 and a SGP identifier is determined based on the SLS value 
and the values of the routing table. The message is then sent on the SCTP association 
5 corresponding to the SGP identifier in step 650. 

It will be appreciated that the present embodiments take the form of a set of computer programs 
intended for use with general purpose computing and signalling platforms and which may be 
marketed in the form of suitable computer program products including the functionality 
10 described. Tt will be appreciated that the invention may equally be implememed as special 
purpose hardware or atiy combination of software and hardNvare. 

Although a specific embodiment of the invention has been described^ the invention is not to be 
limited to the specific arrangement so described. The invention is limited only by the claims. 
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CLAIMS 

1 . A method for operating a signalling gateway process comprising determining routing 
5 infomiation enabling an application server process to identify a signalling gateway process to 

which to direct signalling messages destined for a particular point code and making said 
information available to the application server process. 

2. A method as claimed in claim 1 wherein the information takes ilic form of a routing 
10 table that serves to distribute signalling gateway process identifiers over possible signalling link 

selector values included in signalling messages sent by the application server process. 

3, A method as claimed in any preceding claim comprising responding to a change in the 
status of links upon a route to a particular point code by redetermining the routing information 

IS for that point code and making the redetennined information available to an ^plication server 
process. 

4, A method as claimed in any preceding claim wherein the determined and/or 
redetemained routing information is made available to the application server process in response 

20 to receipt of an audit message from the application server process for a particular destinatioxi 
point code. 

5- A method as claimed in any preceding claim wherein tlie detennined and/or 
redetermined routing information is included in a message transmitted from a signalling 
25 gateway process to an application server process that serves to indicate the availabilty of the 
point code concerned. 

6. A method as claimed in any preceding claim including a registration step comprising 
transmitting a signalling gateway process identifier to an appUcatioa server process. 



^ 30 



7. A method as claimed in claim 6 wherein the signalling gateway process identifier is 
included in an acknowledgement by the signalling gateway process of a message indicating that 
the application server process is ready to receive signalling trafSc. 

« 

35 8. A method for operating an application server process to .sending signalling messages to 
a signalling network via signalling gateway comprising a plurality of signalling gateway 



200314333-1 EP 



Fax regu de : 33 8476149773 



ze/^es/ea* 14:36 Pg: 29 



20 



processes, the method comprising identifying a signallinjj gateway process to which to direct 
signalling messages destined for a pdrticuJar point code by reference to routing information 
received &om a signalling gateway process and SLS values contained in the signalling 
messages. 

5 

9. A method as claimed in claim S wherein the routing information takes the fonn of a 
routing table that serves to distribute signalling gateway process identitiers over possible 
signalling link selector values included in the signalling messages. 

10 10. A method as claimed in claim 8 or claim 9 comprising repeatedly receiving the routing 
information from a signalling gateway process in messages that serve to indicate the availability 
of the point code conc^ned. 

11. A method as claimed in any of claims 8 to 1 0 comprising initiating the repeated sending 
15 of the routing information by including a request in an audit message for a particular destination 

point code sent to a signalling gateway process. 

12. A method as claimed in any of claims 8 to 1 1 including a registration step requesting 
and receiving a signalling gateway process identifier from a signalling gateway process. 

20 • 

13. A method as claimed in claim 12 wherein the registration request is included in a 
message indicating tliat the application server process is ready to receive signalling traffic. 

14. A signalling gateway element arranged to cany out a method as claimed in any of 
25 claims 1 to 7. 

15. A signalling gateway having a redundant set of signalling litiks to a signalling network 
and having a single point code, or set of point codes, therein, and comprising a plurality of 
signalling elements as claimed to claim 14, wth each signalling element comprising a signalling 

30 unit to which a subset of the signalling links are connected. 

16. An application si^cr element arranged to cany out a method as claimed in any of 
claims S to 13. 

35 17. A signalling system comprismg a signalling gateway as claimed in claim 15 within a 
signalling network and having a single point code, or set of point codes* therein, the signalling 
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gateway elemeats of the signalling gateway each having at least one connection with ut Ica^c 
one application server clement as claimed in claim ] 5. 



1 

1 



4 



I 



4 
t 
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ABSTRACT 

METHODS AND APPARATUS FOR CONTROLLING SIGNAL i *>Jfi QATRV/AVS. 

5 

A method is described for operating a signalling gateway comprising detennining information 
enabling an application server to identify a signalling gateway process to which to direct a 
message destined for a particular point code and making said intbnnation available to the 
application server. In preferred embodiments, the infonnation takes the form of a routiTig table 
10 that serves to distribute signalling gateway process identifiers over possible SLS values by, for 
instance, mapping process instance identifiers to possible SLS values for messages sent by the 
application server. By allowing the application server processes the possibility to detCTmine to 
which signalling gateway process each message should be directed, retransmission of messages 
within the signalling gateway can be avoided. 

15 

Fig 4. 
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